Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework PluginRegistry API and introduce VersionMatchRule enum #1163

Merged
merged 3 commits into from
Aug 15, 2024

Conversation

HannesWell
Copy link
Member

@HannesWell HannesWell commented Feb 21, 2024

Modernize the PluginRegistry API that contains the antiquated org.eclipse.osgi.service.resolver.VersionRange by providing alternatives using the org.osgi.framework.VersionRange and deprecating the existing methods for removal.

In conjunction with that also mark PluginRegistry.PluginFilter as deprecated for removal since it is effectively a Predicate<IPluginModelBase> and just use the latter in the new methods.

This is currently an early draft to discuss the overall direction. Since the intention is to focus on the API callers of the now deprecated methods are not replaced in this PR. I'll do that in a follow-up.

About the API I'm also contemplating to further modernize the methods in PluginRegistry that now return a List to return a Stream instead. Then we could also save the filter arguments since callers can just filter the returned stream if desired.

Furthermore I would also like to replace the integer and string constants in IMatchRules by a corresponding Enum VersionMatchRules (or similar) that also provides method to obtain a predicate for a reference version that implements the literals matching rule or to obtain a corresponding VersionRange from a reference version (which ever is needed).

Part of #1069

Copy link

github-actions bot commented Feb 22, 2024

Test Results

   285 files  ±0     285 suites  ±0   47m 32s ⏱️ - 1m 8s
 3 580 tests ±0   3 504 ✅ ±0   76 💤 ±0  0 ❌ ±0 
10 932 runs  ±0  10 701 ✅ ±0  231 💤 ±0  0 ❌ ±0 

Results for commit cbb7f76. ± Comparison against base commit 969eb9b.

♻️ This comment has been updated with latest results.

@HannesWell HannesWell changed the title Replace APIs using equinox VersionRange and PluginRegistry.PluginFilter Rework PluginRegistry API and introduce VersionMatchRule enum Jul 15, 2024
@HannesWell
Copy link
Member Author

This PR now focus only on the rework of the PluginRegistry API and has a adjustments of the pde.project description API moved out into #1340.

In the meantime I made greater changes to the PluginRegistry.findModel(s)() methods and introduced a VersionMatchRule enum. VersionMatchRule represents the rules currently defined in IMatchRules as int constants and handled in various places in the PDE code base in a type-safe manner and also provides the represented logic in one place.

The rework is not yet completely finished, but the overall direction is settled and I would like to gather feedback already.
On the long run the goal is also to replace IMatchRules respectively the usage of int literals by the new VersionMatchRule enum.

*/
@Deprecated(forRemoval = true, since = "3.19 (removal in 2026-09 or later)")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw. what do you think about mentioning the earliest removal date here?
I think it would help consumers to understand better when the actual removal will happen earliest.

Comment on lines +333 to +338
public static Stream<IPluginModelBase> findModels(String id, String version, VersionMatchRule matchRule) {
Version reference = version != null ? Version.valueOf(version) : null;
return selectModels(id, version != null ? p -> matchRule.matches(VersionUtil.getVersion(p), reference) : null);
}
Copy link
Member Author

@HannesWell HannesWell Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having one overload of findModel(s) that accepts a VersionRange and one that accepts a version String plus a VersionMatchRule we could also just provide one method with a VersionRange.
With the new VersionMatchRule one would then use

findModel("foo.bar", EQUIVALENT.rangeFor(version))

instead of

findModel("foo.bar", versionStr, EQUIVALENT)

Of course the level of convenience is also influenced by the fact if one has a Version object or a version String.
Maybe this justifies to keep both so in case one has a Version object the former solution can be used and if one has a version String the latter approach is nicer.

I'm torn on this question.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because there is more than just one difference as described above, I think it is fine to preserve this structure.

@HannesWell
Copy link
Member Author

In general I think this rework is now ready, although there might be a few more minor adjustments necessary.

So anybody interested in this change, please share your opinion as soon as possible.
Otherwise I plan to complete this by the end of this week.

I have also evaluated the possibility to return Optional<IPluginModelBase> in the new overloads of PluginRegistry.findModel() that return null if nothing was found. But this creates an odd asymmetry with respect to the existing overloads. I find it more important to keep the API consistent here. In the other overload that was added recently, we also continued to return null: #1062

@HannesWell HannesWell marked this pull request as ready for review August 7, 2024 06:28
@HannesWell HannesWell force-pushed the version-cleanUps branch 4 times, most recently from 176a783 to 0f3d38f Compare August 15, 2024 21:26
Besides replacing the Equinox resolver VersionRange by the OSGi's
org.osgi.framework.VersionRange, this also removes the rarely used
filter parameter from the findModel() methods. Instead of an array the
new findModels() methods return a stream that can be filtered by the
caller if desired and is sorted by descending plug-in version.

In all cases plug-ins with null IPluginBase or ID are now discarded by
all findModel() methods that accept plug-in id plus version
specification (range or match-rule).

Part of eclipse-pde#1069
@HannesWell HannesWell merged commit 4a9c2a1 into eclipse-pde:master Aug 15, 2024
12 of 13 checks passed
@HannesWell HannesWell deleted the version-cleanUps branch August 15, 2024 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant